home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 9 / QRZ Ham Radio Callsign Database - Volume 9.iso / mac / files / p_term / ad16dis.exe / USERMAN.DOC < prev    next >
Text File  |  1992-12-31  |  23KB  |  499 lines
  1. USERMAN.DOC - ARES/Data Remote Packet User Information
  2.  
  3. Be sure to also read QUIKREF.DOC - Packet Operator Quick Reference
  4. Version 1.6
  5.  
  6.                       OVERVIEW OF ARES/Data
  7.  
  8. Briefly, ARES/Data may be regarded as a specialized multiple-port,
  9. multiple-connect database with a specific command set tailored to the
  10. handling of information input, search, listing, and summary requests.
  11. In addition, the system provides a full-featured conference bridge so
  12. that all connected stations may converse conveniently with one another.
  13.  
  14. The ARES/Data network is a star network with the ARES/Data database
  15. machine at the hub.  It looks something like this:
  16.  
  17.                   _______ARES/Data Database Machine_______
  18.                   |           |             |             |
  19.                Port A       Port B       Port C        Port D
  20.                   |           |             |             |
  21.                 radio       radio         radio         radio
  22.                  ..          ...           ...           ....
  23.                 . .         . . .         . . .         . . . .
  24.                . . .       .  .  .       .  .  .       .  .  . .
  25.               . .   .     .  . .  .     .  . .  .     .  . .  . .
  26.               P P    P    P  P P  P     P  P P  P     P  P P  P P
  27.  
  28. Each "P" represents a remotely-connected packet station which is
  29. connected to the ARES/Data database machine.  All the remotely-connected
  30. stations have shared access to the data in the system.  In particular,
  31. the packet operators can utilize two groups of functions provided by
  32. ARES/Data which are described in detail in this file:
  33.  
  34.       I.  send/receive status requests and current information to/from
  35.           the ARES/Data database station
  36.       II. send/receive short messages to/from other remotely connected
  37.           stations or the sysop (Conference Bridge)
  38.  
  39.  
  40. A.  CONNECTING TO THE ARES/Data DATABASE STATION
  41.  
  42.     TNC SETTINGS FOR REMOTELY CONNECTED PACKET STATIONS:  These are
  43.     quite important for efficient operation of a master/slave network
  44.     like ARES/Data!  Use the commands appropriate for your type of TNC:
  45.  
  46.            TAPR, AEA, PACCOMM:                     WA8DED:
  47.            DWAIT 25 (250 MS)                      * W 25 (250 MS)
  48.            MAXFRAME 1                             * O 1
  49.            FRACK 10 (10 SEC)                      * F 10 (10 SEC)
  50.            RETRY 10                               * N 10
  51.            AX25L2V2 ON                            * V 2
  52.            RESPTIME 10 (1.0 SEC)                  * @T2 100
  53.            TXDELAY 40 (400 ms)                    * T 40 (400 ms)
  54.  
  55.     NOTE: Set paclen larger than the longest input line you expect to use.
  56.     For example, if you will have 4 20-character fields plus an 80 char.
  57.     message, then to include four commas use
  58.            PACLEN 164
  59.  
  60.     Next, using the ARES/Data callsign that has been chosen by the sysop,
  61.     simply initiate a connection.
  62.  
  63.     (Note: if the sysop is running a G8BPQ switch at the main database
  64.     station, this first connect will be to the switch.  Usual commands
  65.     like NODES, ROUTES, etc. are available.  In addition, a new command,
  66.     ARESDATA, will connect you to the ARES/Data application.)
  67.  
  68.     After a successful connect, acknowledged by "ARES/Data System
  69.     Online", you may begin to interact with the database or use the
  70.     conference bridge.  By the way, always be patient in waiting for a
  71.     response from the system - as you can see from the diagram above,
  72.     there may be a large number of operators using the system, and at
  73.     1200 baud, you may have to wait for responses at times.  If you are
  74.     collecting information from a group of voice operators (see Section
  75.     D.4), activate your voice net on the designated simplex frequency if
  76.     needed.  Note that in this case the packet operator needs two
  77.     antennas (one for packet and one for voice) with the antennas
  78.     arranged to eliminate de-sense (unless the packet portion is set up
  79.     on an alternate band, which is preferable).
  80.  
  81.  
  82. B.  WHAT INFORMATION IS STORED IN THE DATABASE
  83.  
  84.     ARES/Data organizes the incoming data into "records", which you can
  85.     view as a group of pieces of information about some particular
  86.     person, place, or thing.  Each record is given a unique "record
  87.     number" by the program.  Here is what can be stored in each record:
  88.  
  89.                   field1,field2,field3,field4,message
  90.  
  91.     where each of fields 1-4 can be a 20-character string, and the
  92.     message string can be 80 characters long.  The distinction between
  93.     the "fields" and the "message" is that the "fields" are organized
  94.     internally by the program so that the packet operator can request
  95.     searches and summaries on the information in any one of the four
  96.     fields.  Searches and summaries cannot be performed on the
  97.     information in the message field.
  98.  
  99.     If this sounds a little abstract, don't worry.  It is one of the
  100.     major virtues of the system that the meaning of the stored
  101.     information is not defined in advance.  In this manner, ARES/Data
  102.     can be used in a variety of ways, depending upon the particular
  103.     disaster or emergency at hand.  In a given event, the sysop can
  104.     issue a "labels" command that gives particular meaning to each of
  105.     the fields and the message, so that all know how ARES/Data is being
  106.     used for that event.
  107.  
  108.     For example, in an evacuation, you may want to keep track of
  109.     evacuees at shelters.  Then you may want the fields to mean:
  110.  
  111.     Name, Shelter, Status, PhoneNumber, Contact person.
  112.  
  113.     On the other hand, if there is a multiple-casualty incident, you may
  114.     want the fields to mean:
  115.  
  116.     Triage number, Sex/Age, Ambulance, Hospital, Condition.
  117.  
  118.     See the paper on ARES/Data in the 7th ARRL Computer Networking
  119.     Conference Proceedings (1988) for more examples.
  120.  
  121.  
  122. C.  GENERAL RULES FOR CURRENT INFORMATION INPUT
  123.  
  124.     (NOTE:  If the database has been set READONLY by the sysop, you will
  125.     not be able to enter information, change information, or delete
  126.     information.  However, you can still search and list the database
  127.     entries.)
  128.  
  129.     Enter the four fields and any message, in order, with separators
  130.     between the fields.  The only valid separator is the comma.  Within
  131.     a field, leading and trailing blanks are ignored, but imbedded
  132.     blanks ARE significant.  If no value is desired for a particular
  133.     field, just skip the field by adding an extra comma.  The database
  134.     will fill that field with ten blank characters.
  135.  
  136.  
  137. D.  SYNTAX FOR CURRENT INFORMATION INPUT:
  138.  
  139.                   field1,field2,field3,field4,message<cr>
  140.  
  141.     (<cr> means carriage return)
  142.  
  143.  
  144.   1.  FIELD1 - FIELD4
  145.  
  146.       The four fields are very general.  Each can have up to 20
  147.       characters, with imbedded blanks.  Entries can be in upper
  148.       or lower case, or a mixture, but are converted to UPPER case
  149.       before being stored in the database.  The meaning of each field is
  150.       defined in real-time by the ARES officials, depending upon the
  151.       nature of the event.  The sysop can issue a "labels" command that
  152.       will give specific names to each of the four fields to help the
  153.       operators remember what they mean.  Similarly, the remote packet
  154.       operator can type "labels<cr>" to see the current label
  155.       definitions.
  156.  
  157.   2.  MESSAGE
  158.  
  159.       MESSAGE is a free-form field that can be up to 80 characters long.
  160.       It could contain a message, a phone number, an address, or other
  161.       information deemed useful for the incident.
  162.  
  163.       AUTOMATIC ORIGIN FEATURE:
  164.  
  165.       When a record is initially entered into ARES/Data, the callsign of
  166.       the originating station is automatically added to the beginning of
  167.       the message field in the format "<W1AW>   rest of message here   ".
  168.       This origin identifier automatically changes if another station
  169.       alters the record later.  As a result of this, the effective length
  170.       of the message field is 80 minus the number of characters in the
  171.       origin identifier, which is usually more like 72 characters.
  172.  
  173.   3.  EXAMPLES OF DATA INPUT
  174.  
  175.             4085553195,joe,12,sj34<cr>
  176.             Johnson,mary,93445,sj13, home 2333 Alsace Ln SJ 617-555-1212<cr>
  177.  
  178.       All of the input information is stored in the database
  179.       as a record of the status and location of a particular person,
  180.       place, or thing at a particular time and date.  The time and date
  181.       are added automatically by the ARES/Data program.  Further STATUS INPUT
  182.       packets for the same person, place, or thing will also be saved
  183.       in the database.  The time and date will identify the most recent
  184.       information.
  185.  
  186.   4.  DETAILED EXAMPLE INPUT TO THE ARES/Data DATABASE
  187.  
  188.       Suppose that the four fields have been defined to be:  LAST NAME,
  189.       FIRST NAME, SHELTER NUMBER, and basic physical CONDITION.  This
  190.       example also assumes that a voice operator is telling the packet
  191.       operator what to type in.  If voice operators are not in use, the
  192.       packet operator simply types the information in directly.
  193.  
  194.       Voice Operator says:                        Packet Operator types:
  195.  
  196.       This is current info,                         (nothing)
  197.       The last name is Johnson                      Johnson,
  198.       The first name is Joe                         Joe,
  199.       The shelter is RS03 (Riverside Shelter 3)     RS03,
  200.       The condition is "okay"                       ok,
  201.       (optional) The message is "came with dog"     came with dog
  202.  
  203.       which should look like this on your terminal:
  204.  
  205.                 Johnson,Joe,RS03,ok,came with dog<CR>
  206.  
  207.       The ARES/Data Database will acknowledge your input, for example, by
  208.  
  209.                 "1450: data input accepted, #234."
  210.  
  211.       or, by sending an error message requiring a re-entry.  The
  212.       acknowledgment contains the current time and the record
  213.       number for that person's entry in the database.  Note that
  214.       the program adds the actual time and date to each entry, which you
  215.       can see when you list the record (see below).
  216.  
  217.       If you later enter more information for the same person, you
  218.       would re-enter the same last and first names, and then enter
  219.       new values for any other fields that have changed.  BOTH entries
  220.       will be kept as a sort of "audit trail" of what has happened to
  221.       that person.  Alternatively, you can just change the value in the
  222.       specific field that has changed (see the next section).
  223.  
  224.  
  225. E.  CORRECTING AND/OR UPDATING INFORMATION
  226.  
  227.     If you accidentally enter incorrect information into the database,
  228.     or if the information in a particular record has changed, you have
  229.     several options.  You can delete the entire record, or you can
  230.     change the value in a specific field of a specific record.
  231.  
  232.     1. DELETING A BAD RECORD:
  233.  
  234.       You can ask the sysop to delete the bad entry by typing:
  235.  
  236.            tell sysop ooops, typo. pse delete #234.<CR>
  237.  
  238.       OR, if the sysop has enabled the remote delete feature, you
  239.       can delete this entry yourself, and then re-enter the correct
  240.       data.  To do this, you first make sure you know the record number,
  241.       then use the delete command:  "d nnnn<CR>"
  242.  
  243.                 d 234<CR>
  244.  
  245.       This function is always enabled at the sysop keyboard.  Its use by
  246.       remotely connected packet stations is controlled initially by the
  247.       configuration file during program startup.  Thereafter, the sysop
  248.       can disable or enable this function as necessary.  Be extremely
  249.       careful in using this command!  Always list the record first
  250.       before deleting to be sure you have the right one.
  251.  
  252.     2. CHANGING (UPDATING) A PARTICULAR FIELD OF A PARTICULAR RECORD:
  253.  
  254.       The syntax for updating fieldm of record nnnn is:
  255.  
  256.       #nnnn,m=new text for fieldm<cr>
  257.  
  258.       where m = 1-4 for the first four fields, and m = 5 for the message.
  259.       For example, suppose you needed to change the value in field3
  260.       of record 235 to "shelter 9".  You would type:
  261.  
  262.       #235,3=shelter 9<cr>
  263.  
  264.       Note that when you correct or update a single field like this, the
  265.       time and date for the record are not changed.  ARES/Data responds
  266.       by showing you what the old values for record 235 were, and what
  267.       the new values are according to your update command.
  268.  
  269.  
  270. F.  INFORMATION THAT MAY BE REQUESTED FROM THE ARES/Data DATABASE
  271.  
  272.     The packet operator can request several types of searches of the
  273.     ARES/Data database.  S/he can request a search for a specific value
  274.     of any one of the four main fields.  In this case, the ARES/Data
  275.     program sends back to the packet operator a status report listing
  276.     all entries in the database having the specified value for the
  277.     selected field.  In addition, the operator can request a "wildcard"
  278.     search, which looks for any entries in a specific field that START
  279.     with a particular string.  The Packet Op can also request a summary
  280.     for any one of the four fields, which is a list of the number of
  281.     entries in the database for each distinct value of that field (see
  282.     Section H).  The operator can list single records in the database by
  283.     specifying the record number.
  284.  
  285.     For example, suppose that for a particular incident, the sysop has
  286.     designated field1 to be the person's last name.  Suppose the packet
  287.     operator needs to find the information on all people in the system
  288.     with a given last name.  The operator sends a search request for
  289.     field1, stating which last name s/he is interested in.  The
  290.     ARES/Data system will respond with all entries with the given name;
  291.     one line for every entry in the database matching that name.  If the
  292.     operator knows only the beginning of the name or if the name is
  293.     long, the wildcard search is very useful.
  294.  
  295.  
  296. G. SEARCH REQUESTS
  297.  
  298.   1.  SYNTAX FOR SEARCH REQUESTS
  299.  
  300.             /1,value<cr>                      for field 1
  301.             /2,value<cr>                      for field 2
  302.             /3,value<cr>                      for field 3
  303.             /4,value<cr>                      for field 4
  304.  
  305.                     or
  306.  
  307.             ?1,value<cr>                      for field 1
  308.             ?2,value<cr>                      for field 2
  309.             ?3,value<cr>                      for field 3
  310.             ?4,value<cr>                      for field 4
  311.  
  312.       This type of packet instructs the database machine to look in the
  313.       database for ALL entries with the same entry as "value" in the
  314.       specified field.  The string "value" must exactly match what was
  315.       originally typed in for the selected field, with leading and
  316.       trailing blanks removed, and without regard for case.  The initial
  317.       character of the search request can be "/" or "?" - use whichever
  318.       is most convenient.  The two formats are handled identically.  A
  319.       status report listing all information for each match is sent back
  320.       to the requesting packet station.  The first line gives the search
  321.       value and the field number.  At the end of the report, the line:
  322.  
  323.             "ARES/Data Search done at 1534, nn hits."
  324.  
  325.       is sent, which signifies no more information coming, and
  326.       that "nn" matches (or hits) were found in the database.
  327.  
  328.   2.  WILDCARD SEARCH OR PARTIAL SEARCH
  329.  
  330.       The syntax for a wildcard or partial search is:
  331.  
  332.         /n,val*<cr>
  333.  
  334.       where "n" is the field number (1-4), and "val*" means that you want to
  335.       search for all entries in fieldn that start with the characters
  336.       "val".  The response from the system is identical to that for an
  337.       exact search request.  This is very useful if a particular field
  338.       has been defined to hold more than one piece of information.  For
  339.       example, suppose field 1 is defined to be "Lastname-Firstname" so
  340.       that Bill Jones would be entered by the line:
  341.  
  342.       Jones-Bill, shelter3, OK, 444-555-1212, message<cr>
  343.  
  344.       Now if you did not know Mr. Jones' first name, you could still
  345.       search for him in the database by typing
  346.  
  347.       ?1,Jone*<cr>
  348.  
  349.       and you would retrieve all records whose first field began with
  350.       the characters "JONE".
  351.  
  352.   3.  DETAILED EXAMPLE OF SEARCH REQUEST
  353.  
  354.       Assume that the label definitions are the same as in D.4
  355.       above.  This example applies to a last name search request
  356.       (field1).
  357.  
  358.       Voice Operator says:                        Packet Operator types:
  359.  
  360.       This is a request for last name search        /1,
  361.       The name is johnson                           johnson
  362.  
  363.       which should look like this on your terminal:
  364.  
  365.                 /1,johnson<CR>
  366.  
  367.       The ARES/Data database will acknowledge your request by either
  368.       stating that there are no entries in the database for that value
  369.       for field1, or by sending a status report which looks like:
  370.  
  371.       Exact Search for value "JOHNSON" in Last name
  372.       Recno    DT/Time  Last name, First name, Shelter, Condition, Msg
  373.       234      23/1124  JOHNSON,JOE,RS03,OK,<W6ABC> CAME WITH DOG
  374.       ARES/Data Search done at 1530, 1 hits.
  375.  
  376.       Some versions of ARES/Data may have disabled the search features
  377.       for certain fields to save disk(ette) space and speed access.
  378.       (And for some situations, it won't make sense to be able to
  379.       search on any field).  If searches have been disabled, you will
  380.       get a message like this one:
  381.  
  382.       Cannot search on this field, index file not in use.
  383.  
  384.  
  385. H.  SUMMARY REQUESTS
  386.  
  387.       $1<cr>                      produces a  list of all distinct
  388.                                   values for field1, with the number
  389.                                   of entries in the database for each
  390.  
  391.       $2<cr>                      similar, except summarize on field 2
  392.       $3<cr>                      similar, except summarize on field 3
  393.       $4<cr>                      similar, except summarize on field 4
  394.  
  395.     For example, suppose field 3 were defined to be the shelter name.
  396.     After the packet operator types "$3<cr>", ARES/Data sends a summary
  397.     on field 3, which may be interpreted as a list of shelters, with the
  398.     number of people that have checked in to each shelter.
  399.  
  400.  
  401. I.  LISTING SPECIFIC ENTRIES (RECORDS) IN THE DATABASE
  402.  
  403.       l nnnn<cr>                  Lists record nnnn
  404.  
  405.       The response will be a short header showing the labels for the
  406.       various fields, and then the complete information for record nnnn.
  407.  
  408.       l nnn,mmm<cr>               Lists records numbered from nnn to mmm
  409.  
  410.       l all<cr>                   List ALL records in the database.
  411.  
  412.            WARNING: be careful with this command, as it may cause a
  413.            large number of packets to be sent on the channel.  You can
  414.            stop an undesired "list all" by simply disconnecting from the
  415.            ARES/Data machine.  This will cause no harm.  Then just
  416.            reconnect.
  417.  
  418.  
  419. J.  DOWNLOADING FILES
  420.  
  421.     You may download a file from a special public directory on the database
  422.     machine by typing:
  423.  
  424.          get filename<cr>
  425.  
  426.     This facility is intended to be used and controlled by the sysop in
  427.     the sense that s/he controls what is in the public subdirectory and
  428.     whether this feature is on or off.  One file that is currently
  429.     provided with ARES/Data is an "info" file, which gives more
  430.     information of interest to general users.  If the sysop has copied
  431.     this file to the public subdirectory, you can download it by typing:
  432.  
  433.          get info<cr>
  434.  
  435.     If the sysop deems that it is useful, this complete documentation
  436.     file can be downloaded by typing "get userman.doc<cr>", but please
  437.     remember that a lot of packets will be generated by this operation.
  438.  
  439.     To get a listing of the files available for downloading from the
  440.     public area, type
  441.  
  442.          dir<cr>
  443.  
  444. K.  CONFERENCE BRIDGE (roundtable - "users" and "tell" commands)
  445.  
  446. This feature allows any connected station to send messages to other
  447. connected stations or to the sysop.
  448.  
  449.   1.  Users command:
  450.  
  451.       The users command, in the form "users<cr>" or "u<cr>", returns a
  452.       list of the callsigns of currently logged-on packet stations.  The
  453.       response is of the form:
  454.  
  455.       Users at WN6I-1 (AX0):  N6KL  W6BB-3  W6XYZ  WB6MRQ-7
  456.       Users at WN6I-4 (DR0):  0:N6KL-3 1:N5BZK 3:AA4RE-12
  457.  
  458.       Note that there is one line for each port defined in the ARES/Data
  459.       system, so that you can see who is using which port.  The
  460.       callsigns used by ARES/Data for the verious defined ports do not
  461.       have to be identical.  After the database callsign, the port name
  462.       defined by the sysop during startup is shown in parentheses.  Note
  463.       also that for the DRSI packet adapter, several radios and even
  464.       several boards can be attached to the database machine.  All the
  465.       users connecting to the DRSI adapters are treated as being on one
  466.       port of the ARES/Data network.  You can refer specifically to the
  467.       user on DRSI sub-port 1 by putting a "1:" in front of the
  468.       callsign:  "1:N5BZK".  In general, however, this is not really
  469.       necessary, since as far as ARES/Data is concerned, "N5BZK" or
  470.       "BZK" will do just as well (see below).
  471.  
  472.   2.  Tell command:
  473.  
  474.       The Tell command allows connected packet stations to use ARES/Data as a
  475.       conference bridge, or roundtable.  The general format is:
  476.  
  477.       tell callsign message<cr>      or:
  478.       t callsign message<cr>
  479.  
  480.       For example:
  481.  
  482.       tell w6bb-3 The food truck just arrived at SJ12<cr>
  483.  
  484.       The message "The food truck just arrived at SJ12" is sent to the
  485.       connected station W6BB-3 prefaced by a time stamp and the call of the
  486.       station originating the tell command.  In this case, if the tell
  487.       command was sent by W6XYX,  W6BB-3 sees:
  488.  
  489.       1230 W6XYZ> The food truck just arrived at SJ12
  490.  
  491.       It is not necessary to enter the entire callsign - just the suffix or
  492.       some other substring will do.  If several connected callsigns contain the
  493.       substring, each station will get the message.  The special callsign
  494.       "*" or "all" is used to send a message to all connected stations.  The
  495.       special callsign "sysop" sends the message to the sysop at the ARES/Data
  496.       database station.
  497.  
  498. END USERMAN.DOC
  499.